fix(subtitle): decrypt LL-HLS VTT AES parts per-part#7881
Merged
robwalch merged 2 commits intoJun 2, 2026
Conversation
SubtitleStreamController only decrypts AES-encrypted VTT data at full-segment boundaries via _handleFragmentLoadComplete. When low-latency parts are in use, each part arrives through the progress callback (_handleFragmentLoadProgress), which the base class leaves as an empty no-op for subtitles. Encrypted parts therefore never fire FRAG_DECRYPTED on the part path, leaving subtitle parsing stuck and adding a segment-duration latency to encrypted VTT captions. This change overrides _handleFragmentLoadProgress in SubtitleStreamController to decrypt each encrypted VTT part as an independent AES-CBC stream using the segment-level IV, and emits FRAG_DECRYPTED with the part reference so the timeline-controller can anchor cues at part.start when appropriate. The full- segment path is reorganised to share the same decryptPayload helper. A 'part: Part | null' field is added to FragDecryptedData and to the two existing FRAG_DECRYPTED emit sites (base-stream-controller init-segment path and subtitle-stream-controller full-segment path) so consumers can distinguish part-level decryption from segment-level decryption.
54ee47e to
6679509
Compare
robwalch
requested changes
May 29, 2026
…nt encrypted check
robwalch
approved these changes
Jun 2, 2026
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
`SubtitleStreamController` only decrypts AES-encrypted VTT data at full-segment boundaries via `_handleFragmentLoadComplete`. When low-latency parts are in use, each part arrives through the progress callback (`_handleFragmentLoadProgress`), which the base class leaves as an empty no-op for subtitles. Concretely:
Net effect: encrypted VTT captions over LL-HLS either stay stuck in `FRAG_LOADING` for the tail parts of a partially-loaded segment, or — at best — only surface after a whole segment is assembled, losing the low-latency benefit.
#7626 covered the part-loading + segment-finding unification but the encrypted-VTT case was out of scope.
Changes
Test plan